BASIC and AST routines

[John Doppke]

So I've been playing with writing AST routines (stubbornly) in BASIC. They work ok, but I've found I have to declare the routine as having 5 'standard' parameters - "function long AST long (p1, p2, p3, p4, p5)". I'm not sure what the 5 parameters are, but doing anything with them is usually a bad idea. I communicate with my main program using common or event flags.

Now I need an AST for a call that requires a parameter - SMG$ENABLE_UNSOLICITED_INPUT. I've tried adding a parameter in my usual list in different ways but I can't get it to work. Every time it's called I get a reserved opcode exception. (A DCLAST call with my AST works ok).

Can anyone shed some light on what the parameters are that BASIC is getting? I'll probably end up writing this one in MACRO, but I want to understand what is happening.

-John

[Jonathan]

function long astRoutine by value(long pasteboard, astArgument, r0, r1, pc, psl)

should work, though how the first two args are passed is hard to determine; experiment with by ref. As you say, messing with the final four args is prone to problems...

[Dave Froble]

From the 7.3 docs:

Table 8–3 AST Arguments for VAX Systems and Alpha Systems
VAX System Arguments Alpha System Arguments
AST parameter AST parameter
R0 R0
R1 R1
PC PC
PSL PS
Registers R0 and R1, the program counter (PC), and the processor status
longword (PSL) on VAX systems, or processor status (PS) on Alpha systems were
saved when the process was interrupted by delivery of the AST.
The AST parameter is an argument passed to the AST service routine so that
it can identify the event that caused the AST. When you call a system service
requesting an AST, or when you call the SYS$DCLAST system service, you
can supply a value for the AST parameter. If you do not specify a value, the
parameter defaults to 0.

Not formatted so well, but the important data is there.

You get to pass a longword to the AST routine. The other 4 parameters appear to
be set by the OS, or whatever. Not by you! I don't know what you'd do with R0,
R1, PC, and PLS/PS.

Other communications would be via global data, a COMMON block, a PSECT, and
whatever.

As an example, something I've done, set a timer on some I/O. When the AST
fires, you want to do something because of the timeout. I pass the channel #
for the I/O and have the AST cancel the I/O on that channel and return. That
causes I/O completion in the code that set the timer.

I've not used SMG, so I'm not much help in what you're doing. But I'd guess the
"SMG$ENABLE_UNSOLICITED_INPUT" would be an external value, and the use of an
INCLUDE statement would make it available, or, in global data shared with the
calling code.

Apologies if I've not understood your question.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[John Doppke]

Thanks. It also helps if you don't have a typo referring to your function. BASIC will happily compile and link and not say a word.

[Simon Clubley]

On 2021-11-18, John Doppke <jdo...@gmail.com> wrote:
>
> Thanks. It also helps if you don't have a typo referring to your function. BASIC will happily compile and link and not say a word.

Huh ? Why don't you get an undefined function error ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

[Dave Froble]

On 11/18/2021 1:47 PM, Simon Clubley wrote:
> On 2021-11-18, John Doppke <jdo...@gmail.com> wrote:
>>
>> Thanks. It also helps if you don't have a typo referring to your function. BASIC will happily compile and link and not say a word.
>
> Huh ? Why don't you get an undefined function error ?
>
> Simon.
>

Because the compiler is smart enough to rub your nose in your mistakes ??

[VAXman-]

In article <d77053df-ac45-42f9...@googlegroups.com>, John Doppke <jdo...@gmail.com> writes:
>So I've been playing with writing AST routines (stubbornly) in BASIC. They=
> work ok, but I've found I have to declare the routine as having 5 'standar=
>d' parameters - "function long AST long (p1, p2, p3, p4, p5)". I'm not sur=
>e what the 5 parameters are, but doing anything with them is usually a bad =

>idea. I communicate with my main program using common or event flags.
>

>Now I need an AST for a call that requires a parameter - SMG$ENABLE_UNSOLIC=
>ITED_INPUT. I've tried adding a parameter in my usual list in different wa=
>ys but I can't get it to work. Every time it's called I get a reserved opc=

>ode exception. (A DCLAST call with my AST works ok).
>

>Can anyone shed some light on what the parameters are that BASIC is getting=
>? I'll probably end up writing this one in MACRO, but I want to understand=
> what is happening.

AST parameter, R0, R1, PC, PSL/PS

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

[Craig A. Berry]

There is an example in the docs here:

<https://docs.vmssoftware.com/vsi-openvms-rtl-screen-management-smg-manual/#_5935disable_broadcast_trapping>

of calling SMG$ENABLE_UNSOLICITED_INPUT. The example does not work
as-is on post-Alpha architectures -- you have to declare the AST
routines as FUNCTION INTEGER and not SUB. But as far as parameter
passing, if memory serves, what it does works.

[Bob Gezelter]

On Wednesday, November 17, 2021 at 6:14:30 PM UTC-5, John Doppke wrote:

John,

Been there, done that (for a client whose entire codebase was written in BASIC).

As VAXman and Dave Froble noted, the five parameters are passed are, and I quote from David's posting:

"From the 7.3 docs:

Table 8–3 AST Arguments for VAX Systems and Alpha Systems
VAX System Arguments Alpha System Arguments
AST parameter AST parameter
R0 R0
R1 R1
PC PC
PSL PS "

One will notice that the correct number of parameters restriction does not appear in all languages. C , FORTRAN, and others have looser restrictions on parameter lists, as well as variable-sized parameter lists. BASIC does not. BASIC requires that the parameter lists match in size and type AND enforces that restriction at the called routine interface. In the OpenVMS DOC set, I have seen examples which presume that the parameter count restriction is not enforced. They are a bit misleading in the case of BASIC.

Many library routines can be called from both normal thread and AST contexts, but since many of the library routines are not- re-entrant, one cannot generally call library routines from both AST and process threads. However, most OpenVMS general library routines and system services are reentrant, and can be invoked without excessive difficulty from BASIC. While many define their own prototypes I highly recommending the include files from the BASIC text library in SYS$LIBRARY. If those are out of date, write your own versions with correct parameter list definitions, correctly implemented definitions save a lot of fighting with debugging.

As to what is the AST parameter, my general practice is to use a data structure for each file, and pass a pointer to that file as the AST parameter. That allows storage of useful information beyond the file number/handle.

- Bob Gezelter, http://wwww.rlgsc.com

[Chris Townley]

IIRC Basic can handle variable number of parameters when calling a
sub/function, but you cannot write them in Basic


--
Chris

[Bob Gezelter]

Chris,

Not relevant. I the case referenced, the AST, written in BASIC, is the CALLED routine. As to what can be called from BASIC, I suggest reading the reference manual. As I recall, the original header files had no parameter definitions, so it was possible to easily fall into the trap. Later versions allowed more precision, but the older form was preserved for backward compatibility.

Of course, more than a few people did not pick up the change and continued the earlier approach, which leads to problems.

- Bob Gezelter, http://www.rlgsc.com

[Dave Froble]

I'm going to confess to curiosity. Why are R0, R1, SP, and PC passed to an AST
routine?

[Bob Gezelter]

David,

Am rather busy this morning, but the IDSM has a full description of the dispatching process for an AST.

[Stephen Hoffman]

On 2021-11-19 05:35:20 +0000, Dave Froble said:

> I'm going to confess to curiosity. Why are R0, R1, SP, and PC passed
> to an AST routine?

Technically, because VAX.

VAX never saved R0 and R1 across CALLS/CALLG calls as those registers
were the return value path, and PC and PS/PSL are the rest of restoring
the context around the AST. If those registers didn't get preserved
(somewhere) across the AST, then the AST delivery would corrupt the
mainline.

Pragmatically, because the programming languages that the OpenVMS devs
largely utilized (then and now) could ignore those arguments, and "the
right thing" would happen. (There's a side-discussion in argument
mismatching to be had here, too.)

In aggregate, it's a dumb-arsed API design that exposes the hardware,
and one that will probably only change as part of overhauling BASIC for
64-bit and for more modern expectations. And possibly of overhauling
the OpenVMS APIs.

Minimally, better BASIC doc would be nice, as the AST API has
eventually bitten most BASIC developers, this stuff is ~not documented.
Searching for "asynchronous" in the current BASIC user and reference
manuals gets nada, and searching for "AST" in the user guide has
nothing useful for writing an AST routine in BASIC and nothing in the
reference manual. This would be where a discussion of AST and thread
reentrancy would likely be placed, too.

Smallest and most isolated VSI code change would be an added AST
function keyword that would allow those arguments to be preserved by
the BASIC run-time, but suppressed in the BASIC app source code.
Syntactic sugar in the BASIC compiler.

Moderate to larger changes would involve moving OpenVMS and BASIC to
object support, and with a hypothetical object AST routine would get an
object containing everything, and the app source code would never need
to reference those bits of hardware data. Or as ASTs are a predecessor
to threading, replace ASTs for KP threading or GCD/libdispatch-style
threading save for preserving the existing old-style-API AST source
code. But last I checked, BASIC was AST-safe and not thread-safe, so
this threading overhaul and object-overhaul would be a
comparatively large investment in the future of BASIC.



--
Pure Personal Opinion | HoffmanLabs LLC

[Dave Froble]

Oh, you mean that big book on the bookshelf gathering dust?

Got to now consider how curious I really am.

[Dave Froble]

All very interesting, and yes, I asked, so thanks for the info.

The real problem is John still doesn't have a Basic compiler for x86, which just
might be a bit more important than how ASTs work. I'll just be real happy when
he has an x86 Basic compiler. I'm not too hard to please.

:-)

[VAXman-]

In article <sn8nrg$g7b$1...@dont-email.me>, Dave Froble <da...@tsoft-inc.com> writes:
>On 11/19/2021 6:43 AM, Bob Gezelter wrote:

>> On Friday, November 19, 2021 at 12:35:24 AM UTC-5, Dave Froble wrote:
>>> On 11/18/2021 10:49 PM, Bob Gezelter wrote:
>>>> On Thursday, November 18, 2021 at 8:08:47 PM UTC-5, Chris Townley wrote:
>>>>> On 18/11/2021 23:31, Bob Gezelter wrote:
>>>>>> On Wednesday, November 17, 2021 at 6:14:30 PM UTC-5, John Doppke wrote:
>>>>>>> So I've been playing with writing AST routines (stubbornly) in BASIC. They work ok, but I've found I have to declare the routine as having 5 'standard' parameters - "function long AST long (p1, p2, p3, p4, p5)". I'm not sure what the 5 parameters
>>>>>>>

>>>>>>> Now I need an AST for a call that requires a parameter - SMG$ENABLE_UNSOLICITED_INPUT. I've tried adding a parameter in my usual list in different ways but I can't get it to work. Every time it's called I get a reserved opcode exception. (A DCLAST
>>>>>>>

>>>>>>> Can anyone shed some light on what the parameters are that BASIC is getting? I'll probably end up writing this one in MACRO, but I want to understand what is happening.
>>>>>>>
>>>>>>> -John
>>>>>> John,
>>>>>>
>>>>>> Been there, done that (for a client whose entire codebase was written in BASIC).
>>>>>>
>>>>>> As VAXman and Dave Froble noted, the five parameters are passed are, and I quote from David's posting:
>>>>>>
>>>>>> "From the 7.3 docs:
>>>>>>
>>>>>> Table 8–3 AST Arguments for VAX Systems and Alpha Systems
>>>>>> VAX System Arguments Alpha System Arguments
>>>>>> AST parameter AST parameter
>>>>>> R0 R0
>>>>>> R1 R1
>>>>>> PC PC
>>>>>> PSL PS "
>>>>>>
>>>>>> One will notice that the correct number of parameters restriction does not appear in all languages. C , FORTRAN, and others have looser restrictions on parameter lists, as well as variable-sized parameter lists. BASIC does not. BASIC requires that
>>>>>>

>>>>>> Many library routines can be called from both normal thread and AST contexts, but since many of the library routines are not- re-entrant, one cannot generally call library routines from both AST and process threads. However, most OpenVMS general li
>>>>>>

>>>>>> As to what is the AST parameter, my general practice is to use a data structure for each file, and pass a pointer to that file as the AST parameter. That allows storage of useful information beyond the file number/handle.
>>>>>>
>>>>>> - Bob Gezelter, http://wwww.rlgsc.com
>>>>>>
>>>>> IIRC Basic can handle variable number of parameters when calling a
>>>>> sub/function, but you cannot write them in Basic
>>>>>
>>>>>
>>>>> --
>>>>> Chris
>>>> Chris,
>>>>
>>>> Not relevant. I the case referenced, the AST, written in BASIC, is the CALLED routine. As to what can be called from BASIC, I suggest reading the reference manual. As I recall, the original header files had no parameter definitions, so it was possibl
>>>>

>>>> Of course, more than a few people did not pick up the change and continued the earlier approach, which leads to problems.
>>>>
>>>> - Bob Gezelter, http://www.rlgsc.com
>>>>
>>> I'm going to confess to curiosity. Why are R0, R1, SP, and PC passed to an AST
>>> routine?
>>> --
>>> David Froble Tel: 724-529-0450
>>> Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
>>> DFE Ultralights, Inc.
>>> 170 Grimplin Road
>>> Vanderbilt, PA 15486
>> David,
>>
>> Am rather busy this morning, but the IDSM has a full description of the dispatching process for an AST.
>>
>> - Bob Gezelter, http://www.rlgsc.com
>>
>

>Oh, you mean that big book on the bookshelf gathering dust?
>
>Got to now consider how curious I really am.

RTFM!

[Neil Rieck]

John etc al,

Back in the day, I was under the impression that I could do almost anything I wanted in DEC-BASIC (given enough time). You mentioned the 5 standard parameters. I recall being here as well when I was first attempting to write my own code to call SYS$QIO and SYS$QIOW. It was around that time that I discovered errors in the official VMS documentation that did not agree with how things were done in the STARLET library. Anyway, here are three links: the first one is for doing $QIO from BASIC (one of the QIO examples includes an AST). The second is a "dog's breakfast menu" of my mostly DEC-BASIC demo code. The third is a menu of VMS notes where one entry shows you how to open any system library so you can see how things need to be declared for the language in question. Enjoy!

http://neilrieck.net/demo_vms_html/qio_demo_bas.html
http://neilrieck.net/demo_vms_html/openvms_demo_index.html
http://neilrieck.net/links/openvms_resources.html#openvms-notes

Neil Rieck
Waterloo, Ontario, Canada

[Simon Clubley]

On 2021-11-19, Dave Froble <da...@tsoft-inc.com> wrote:
>
> I'm going to confess to curiosity. Why are R0, R1, SP, and PC passed to an AST
> routine?
>

Because it's another example of VMS functionality being implemented
at way too low an abstraction level because of the need to support
Macro-32 as an application programming language.

In a modern version of VMS, that would be hidden from the application
programmer as an implementation detail and the most you would have to
do would be to tag the AST routine with a pragma or some type of __ast__
attribute that the compiler understood and then automatically generated
the right code for you.

[Simon Clubley]

On 2021-11-19, Dave Froble <da...@tsoft-inc.com> wrote:

That "big book" has lots of interesting stuff in it. Try reading
it sometime. :-)

[VAXman-]

In article <sngp1p$aud$2...@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2021-11-19, Dave Froble <da...@tsoft-inc.com> wrote:
>>
>> I'm going to confess to curiosity. Why are R0, R1, SP, and PC passed to an AST
>> routine?
>>
>
>Because it's another example of VMS functionality being implemented
>at way too low an abstraction level because of the need to support
>Macro-32 as an application programming language.

BULLSHIT! If you believe that's true, please provide an illustrating example.
I'll be waiting...

>In a modern version of VMS, that would be hidden from the application
>programmer as an implementation detail and the most you would have to
>do would be to tag the AST routine with a pragma or some type of __ast__
>attribute that the compiler understood and then automatically generated
>the right code for you.

Most will NEVER need to access those parameter and attempts to change them will
do nothing. ASTPRM is first and that's all you may need. Consider the others
gratuitous FYI.

[Simon Clubley]

On 2021-11-22, VAXman- @SendSpamHere.ORG <VAX...@SendSpamHere.ORG> wrote:
> In article <sngp1p$aud$2...@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>On 2021-11-19, Dave Froble <da...@tsoft-inc.com> wrote:
>>>
>>> I'm going to confess to curiosity. Why are R0, R1, SP, and PC passed to an AST
>>> routine?
>>>
>>
>>Because it's another example of VMS functionality being implemented
>>at way too low an abstraction level because of the need to support
>>Macro-32 as an application programming language.
>
> BULLSHIT! If you believe that's true, please provide an illustrating example.
> I'll be waiting...
>

That VMS API passes in a stack pointer, a PC and what were originally
two architecture-specific registers.

That kind of information simply would not be exposed at application
code level in a modern version of that API as it would (rightly) be
treated as an implementation specific detail that would be handled
by the compiler.

That information is only needed because the lowest supported application
language on VMS is Macro-32 and not C (or another comparable low-level
language).

[Arne Vajhøj]

On 11/23/2021 1:37 PM, Simon Clubley wrote:
> On 2021-11-22, VAXman- @SendSpamHere.ORG <VAX...@SendSpamHere.ORG> wrote:
>> In article <sngp1p$aud$2...@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>> On 2021-11-19, Dave Froble <da...@tsoft-inc.com> wrote:
>>>>
>>>> I'm going to confess to curiosity. Why are R0, R1, SP, and PC passed to an AST
>>>> routine?
>>>>
>>>
>>> Because it's another example of VMS functionality being implemented
>>> at way too low an abstraction level because of the need to support
>>> Macro-32 as an application programming language.
>>
>> BULLSHIT! If you believe that's true, please provide an illustrating example.
>> I'll be waiting...
>
> That VMS API passes in a stack pointer, a PC and what were originally
> two architecture-specific registers.
>
> That kind of information simply would not be exposed at application
> code level in a modern version of that API as it would (rightly) be
> treated as an implementation specific detail that would be handled
> by the compiler.
>
> That information is only needed because the lowest supported application
> language on VMS is Macro-32 and not C (or another comparable low-level
> language).

What does the Macro-32 application developers need those
arguments for that the C application developers does not need
them for?

Arne

[Simon Clubley]

You miss the point Arne.

If C was the lowest level supported language then the compiler would
simply have a pragma or function attribute that marked it as an AST
routine so that the compiler would generate the required code (or not
generate troublesome code sequences) as required.

This happens all the time with C language interrupt handlers in some
embedded environments for example.

The SP/PC/R0/R1 parameters are implementation details that the person
writing the AST routine should never see or have to deal with.

[Arne Vajhøj]

????

There are two questions here.

1) How to deal with side effects from those arguments.

Basic apparently has a problem. It could be fixed like you describe
for C. John Reagan already confirmed that.

Neither C nor Macro-32 has the need for such a fix. They just
don't access the argument and they are good.

2) Why are those arguments there?

It is not obvious to me why Macro-32 code would want to use them
any more than C or Basic code.

Arne

[VAXman-]

In article <snjcd1$9hn$2...@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2021-11-22, VAXman- @SendSpamHere.ORG <VAX...@SendSpamHere.ORG> wrote:

>> In article <sngp1p$aud$2...@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>On 2021-11-19, Dave Froble <da...@tsoft-inc.com> wrote:
>>>>
>>>> I'm going to confess to curiosity. Why are R0, R1, SP, and PC passed to an AST
>>>> routine?
>>>>
>>>
>>>Because it's another example of VMS functionality being implemented
>>>at way too low an abstraction level because of the need to support
>>>Macro-32 as an application programming language.
>>
>> BULLSHIT! If you believe that's true, please provide an illustrating example.
>> I'll be waiting...
>>
>

>That VMS API passes in a stack pointer, a PC and what were originally
>two architecture-specific registers.

That doesn't answer your aspersions WRT Macro-32. Try, do try again.
I'll be waiting. Also, please tell me about this stack pointer you've
now claimed to be passed along too.

>That kind of information simply would not be exposed at application
>code level in a modern version of that API as it would (rightly) be
>treated as an implementation specific detail that would be handled
>by the compiler.

Oh, please explain then how are ASTs handled in *ix? <LOL>

>That information is only needed because the lowest supported application
>language on VMS is Macro-32 and not C (or another comparable low-level
>language).

You're slinging your BULLSHIT yet again. Macro-32 has no inherent need
or want to know R0, R1, the PC at AST delivery or the PS/PSL. As I have
requested previously, if you want to be slinging manure in here, please
show us your shovel.

[VAXman-]

In article <619d35db$0$706$1472...@news.sunsite.dk>, =?UTF-8?Q?Arne_Vajh=c3=b8j?= <ar...@vajhoej.dk> writes:
>On 11/23/2021 1:37 PM, Simon Clubley wrote:

>> On 2021-11-22, VAXman- @SendSpamHere.ORG <VAX...@SendSpamHere.ORG> wrote:
>>> In article <sngp1p$aud$2...@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>> On 2021-11-19, Dave Froble <da...@tsoft-inc.com> wrote:
>>>>>
>>>>> I'm going to confess to curiosity. Why are R0, R1, SP, and PC passed to an AST
>>>>> routine?
>>>>>
>>>>
>>>> Because it's another example of VMS functionality being implemented
>>>> at way too low an abstraction level because of the need to support
>>>> Macro-32 as an application programming language.
>>>
>>> BULLSHIT! If you believe that's true, please provide an illustrating example.
>>> I'll be waiting...
>>
>> That VMS API passes in a stack pointer, a PC and what were originally
>> two architecture-specific registers.
>>
>> That kind of information simply would not be exposed at application
>> code level in a modern version of that API as it would (rightly) be
>> treated as an implementation specific detail that would be handled
>> by the compiler.
>>
>> That information is only needed because the lowest supported application
>> language on VMS is Macro-32 and not C (or another comparable low-level
>> language).
>

>What does the Macro-32 application developers need those
>arguments for that the C application developers does not need
>them for?

Manure slinging, of course.

[VAXman-]

In article <619d417a$0$699$1472...@news.sunsite.dk>, =?UTF-8?Q?Arne_Vajh=c3=b8j?= <ar...@vajhoej.dk> writes:

>????
>
>There are two questions here.
>
>1) How to deal with side effects from those arguments.
>
>Basic apparently has a problem. It could be fixed like you describe
>for C. John Reagan already confirmed that.

I don't see why BASIC should have any issue either.

>Neither C nor Macro-32 has the need for such a fix. They just
>don't access the argument and they are good.

Correct. Use them on a need to know basis.

>2) Why are those arguments there?
>
>It is not obvious to me why Macro-32 code would want to use them
>any more than C or Basic code.

Precisely! However, according to our manure slinger in chief, ASTs are
delivered with those extra parameters' values because Macro-32 would be
spanking the monkey in some dark corner without them.

[Dave Froble]

On 11/23/2021 1:37 PM, Simon Clubley wrote:

> On 2021-11-22, VAXman- @SendSpamHere.ORG <VAX...@SendSpamHere.ORG> wrote:
>> In article <sngp1p$aud$2...@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>> On 2021-11-19, Dave Froble <da...@tsoft-inc.com> wrote:
>>>>
>>>> I'm going to confess to curiosity. Why are R0, R1, SP, and PC passed to an AST
>>>> routine?
>>>>
>>>
>>> Because it's another example of VMS functionality being implemented
>>> at way too low an abstraction level because of the need to support
>>> Macro-32 as an application programming language.
>>
>> BULLSHIT! If you believe that's true, please provide an illustrating example.
>> I'll be waiting...
>>
>
> That VMS API passes in a stack pointer, a PC and what were originally
> two architecture-specific registers.
>
> That kind of information simply would not be exposed at application
> code level in a modern version of that API as it would (rightly) be
> treated as an implementation specific detail that would be handled
> by the compiler.
>
> That information is only needed because the lowest supported application
> language on VMS is Macro-32 and not C (or another comparable low-level
> language).
>
> Simon.
>

Ok, but, what is the harm?

Perhaps there are uses for that data. If one doesn't need to use them, ignore
them. No blood, no foul.

Just because something is not "how things should be according to Simon" doesn't
necessarily make that something bad.

Perhaps when using Macro-32 there might be some use. Yes, Macro-32 as a
compiler language sort of sucks. But what's your alternative? Re-write
everything each year, even if it's working as designed and needed?

[Dave Froble]

Ya know, that sort of gets back to my question ...

[Dave Froble]

No, Basic does not have any problems. Works just fine. No use for arguments
2,3,4,5, just ignore them.

> Neither C nor Macro-32 has the need for such a fix. They just
> don't access the argument and they are good.

Same with Basic.

> 2) Why are those arguments there?

Now there is the interesting question. Does anyone think they would have been
implemented if there was no use for them? There is or was a reason, even if it
was done in case some future use might need them.

[Arne Vajhøj]

True. But they need to be declared. That was the observation that
started this thread.

BTW, I think it was Hoff not John Reagan that talked about a
keyword to "hide" those arguments. Mea culpa.

>> Neither C nor Macro-32 has the need for such a fix. They just
>> don't access the argument and they are good.
>
> Same with Basic.

But in those language you do not even need to declare them.

Arne

[Arne Vajhøj]

On 11/23/2021 8:34 PM, Dave Froble wrote:
> On 11/23/2021 1:37 PM, Simon Clubley wrote:
>> That VMS API passes in a stack pointer, a PC and what were originally
>> two architecture-specific registers.
>>
>> That kind of information simply would not be exposed at application
>> code level in a modern version of that API as it would (rightly) be
>> treated as an implementation specific detail that would be handled
>> by the compiler.
>>
>> That information is only needed because the lowest supported application
>> language on VMS is Macro-32 and not C (or another comparable low-level
>> language).
>

> Ok, but, what is the harm?
>
> Perhaps there are uses for that data.  If one doesn't need to use them,
> ignore them.  No blood, no foul.
>
> Just because something is not "how things should be according to Simon"
> doesn't necessarily make that something bad.
>
> Perhaps when using Macro-32 there might be some use.  Yes, Macro-32 as a
> compiler language sort of sucks.  But what's your alternative?  Re-write
> everything each year, even if it's working as designed and needed?

Rewrite comes with both short term cost and risk.

But not rewriting comes with long term cost and risk.

Rewriting every year is crazy. But rewrite every 10 or 15 or 20 years
and always to something higher level may make sense.

Arne

[Simon Clubley]

On 2021-11-23, VAXman- @SendSpamHere.ORG <VAX...@SendSpamHere.ORG> wrote:
> In article <snjcd1$9hn$2...@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>
>>That VMS API passes in a stack pointer, a PC and what were originally
>>two architecture-specific registers.
>
> That doesn't answer your aspersions WRT Macro-32. Try, do try again.
> I'll be waiting. Also, please tell me about this stack pointer you've
> now claimed to be passed along too.
>

You are correct Brian. I wrongly thought it was the SP for some reason
instead of the PS/PSL. However, passing an architecture-specific PS/PSL
register to the AST is even more ridiculous than passing the SP.

>
>
>>That kind of information simply would not be exposed at application
>>code level in a modern version of that API as it would (rightly) be
>>treated as an implementation specific detail that would be handled
>>by the compiler.
>
> Oh, please explain then how are ASTs handled in *ix? <LOL>
>

Here is one example of how asynchronous callbacks are handled in Linux:

https://linux.die.net/man/3/dlm_lock

For a proper hardware-level callback when code is written in C, looking
at microcontroller interrupt handlers would be a good example.

In that world, you can either tag the interrupt handler with an __ISR
attribute and let the compiler generate the correct code for you, or
the underlying OS environment can wrap calls to the C language interrupt
handler with an assembly language handler that is utterly invisible to
the C language interrupt handler itself.

Here is how one compiler for the PIC32MX (a MIPS MCU) handles this:

https://microchipdeveloper.com/32bit:mx-arch-exceptions-usage

>
>
>>That information is only needed because the lowest supported application
>>language on VMS is Macro-32 and not C (or another comparable low-level
>>language).
>
> You're slinging your BULLSHIT yet again. Macro-32 has no inherent need
> or want to know R0, R1, the PC at AST delivery or the PS/PSL. As I have
> requested previously, if you want to be slinging manure in here, please
> show us your shovel.
>

Fine. So why are these architecture-specific registers passed to what
is essentially a callback function in a normal application program
and why do those registers need to be visible from that same callback
function ?

[Arne Vajhøj]

So far there has only been one guess: yours - that it is to
support applications in Macro-32. And that explanation does
not make any sense as Macro-32 applications do not need info
that C applications does not.

Arne

[Simon Clubley]

Nor to me. In an OS with the proper levels of abstraction, those
hardware-specific registers simply should not be needed (or even
visible) to a function used as the target of what is essentially
just another way of doing an asynchronous callback to a function
within an application.

Since they are visible, and since they are of no use to a normal
compiled language, there must be some cases where you have to
preserve these values manually in Macro-32, whereas a OS based
around a higher-level language would have its compilers generate
the correct code sequences for you without you having to worry
about any of this at all.

[Simon Clubley]

Not directly, but you might have to manually manage or preserve
something in Macro-32 that an OS based around a higher-level language
could handle for you automatically in the code generated by the
compilers for that OS.

[Arne Vajhøj]

On 11/24/2021 8:46 AM, Simon Clubley wrote:
> On 2021-11-23, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>
>> 2) Why are those arguments there?
>>
>> It is not obvious to me why Macro-32 code would want to use them
>> any more than C or Basic code.
>>
>
> Nor to me. In an OS with the proper levels of abstraction, those
> hardware-specific registers simply should not be needed (or even
> visible) to a function used as the target of what is essentially
> just another way of doing an asynchronous callback to a function
> within an application.

So why did you suggest that it was for Macro-32?

> Since they are visible, and since they are of no use to a normal
> compiled language, there must be some cases where you have to
> preserve these values manually in Macro-32, whereas a OS based
> around a higher-level language would have its compilers generate
> the correct code sequences for you without you having to worry
> about any of this at all.

So it is there for Macro-32 because VMS C could have had a feature
but actually does not that does something that nobody seems to be doing?

And are there really any difference between the non-existing C:

int __damn_ast foobar()

and the non-existing Macro-32:

.entry foobar
.damn_ast

?

Arne

[Arne Vajhøj]

Except that it is fine to ignore those arguments.

And except that there is no such feature in VMS C.

Arne

[VAXman-]

In article <snlerq$jrr$1...@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

>On 2021-11-23, VAXman- @SendSpamHere.ORG <VAX...@SendSpamHere.ORG> wrote:
>> In article <snjcd1$9hn$2...@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>
>>>That VMS API passes in a stack pointer, a PC and what were originally
>>>two architecture-specific registers.
>>
>> That doesn't answer your aspersions WRT Macro-32. Try, do try again.
>> I'll be waiting. Also, please tell me about this stack pointer you've
>> now claimed to be passed along too.
>>
>

>You are correct Brian. I wrongly thought it was the SP for some reason
>instead of the PS/PSL. However, passing an architecture-specific PS/PSL
>register to the AST is even more ridiculous than passing the SP.
>
>>
>>

>>>That kind of information simply would not be exposed at application
>>>code level in a modern version of that API as it would (rightly) be
>>>treated as an implementation specific detail that would be handled
>>>by the compiler.
>>
>> Oh, please explain then how are ASTs handled in *ix? <LOL>
>>
>

>Here is one example of how asynchronous callbacks are handled in Linux:
>
>https://linux.die.net/man/3/dlm_lock
>
>For a proper hardware-level callback when code is written in C, looking
>at microcontroller interrupt handlers would be a good example.
>
>In that world, you can either tag the interrupt handler with an __ISR
>attribute and let the compiler generate the correct code for you, or
>the underlying OS environment can wrap calls to the C language interrupt
>handler with an assembly language handler that is utterly invisible to
>the C language interrupt handler itself.
>
>Here is how one compiler for the PIC32MX (a MIPS MCU) handles this:
>
>https://microchipdeveloper.com/32bit:mx-arch-exceptions-usage
>
>>
>>

>>>That information is only needed because the lowest supported application
>>>language on VMS is Macro-32 and not C (or another comparable low-level
>>>language).
>>
>> You're slinging your BULLSHIT yet again. Macro-32 has no inherent need
>> or want to know R0, R1, the PC at AST delivery or the PS/PSL. As I have
>> requested previously, if you want to be slinging manure in here, please
>> show us your shovel.
>>
>

>Fine. So why are these architecture-specific registers passed to what
>is essentially a callback function in a normal application program
>and why do those registers need to be visible from that same callback
>function ?

Stop there! You stated crap, pure unadulterated crap! Answer the initial
question! You're trying to drag this off the main street and down a side
alley where it'll be lost amongst the riff-raff.

[Simon Clubley]

On 2021-11-24, Arne Vajhøj <ar...@vajhoej.dk> wrote:

> On 11/24/2021 8:46 AM, Simon Clubley wrote:
>> On 2021-11-23, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>>
>>> 2) Why are those arguments there?
>>>
>>> It is not obvious to me why Macro-32 code would want to use them
>>> any more than C or Basic code.
>>>
>>
>> Nor to me. In an OS with the proper levels of abstraction, those
>> hardware-specific registers simply should not be needed (or even
>> visible) to a function used as the target of what is essentially
>> just another way of doing an asynchronous callback to a function
>> within an application.
>
> So why did you suggest that it was for Macro-32?
>

I suggested it was needed because clearly something needs to be manually
preserved by the programmer in Macro-32 code that simply would not be
an issue if VMS was based around an higher-level language instead.

>> Since they are visible, and since they are of no use to a normal
>> compiled language, there must be some cases where you have to
>> preserve these values manually in Macro-32, whereas a OS based
>> around a higher-level language would have its compilers generate
>> the correct code sequences for you without you having to worry
>> about any of this at all.
>
> So it is there for Macro-32 because VMS C could have had a feature
> but actually does not that does something that nobody seems to be doing?
>

No, it's there because the lowest supported application language on
VMS is Macro-32 instead of C or another language and hence that had
to be factored into the VMS API design.

> And are there really any difference between the non-existing C:
>
> int __damn_ast foobar()
>
> and the non-existing Macro-32:
>
> .entry foobar
> .damn_ast
>

Yes. Code generation in a compiled language is totally abstracted
away from the source code the compiler is working with.

In Macro-32, the assembler is translating the source code, not
rewriting it, and hence there are only a small number of transformations
it can do on the source code.

[Simon Clubley]

No, I am not. Are the arguments passed to the AST because the Macro-32
programmer has to manually preserve them in some cases ?

The same kind of thing that a programmer would never have to worry
about if the lowest supported language on VMS was not Macro-32 ?

[Dave Froble]

On 11/24/2021 8:31 AM, Simon Clubley wrote:

Steve Hoffman answered that question way back up-thread. I'll leave it as an
exercise for you to go back and take a look.

[Arne Vajhøj]

On 11/24/2021 9:08 AM, Simon Clubley wrote:
> On 2021-11-24, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 11/24/2021 8:46 AM, Simon Clubley wrote:
>>> On 2021-11-23, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>>>
>>>> 2) Why are those arguments there?
>>>>
>>>> It is not obvious to me why Macro-32 code would want to use them
>>>> any more than C or Basic code.
>>>>
>>>
>>> Nor to me. In an OS with the proper levels of abstraction, those
>>> hardware-specific registers simply should not be needed (or even
>>> visible) to a function used as the target of what is essentially
>>> just another way of doing an asynchronous callback to a function
>>> within an application.
>>
>> So why did you suggest that it was for Macro-32?
>
> I suggested it was needed because clearly something needs to be manually
> preserved by the programmer in Macro-32 code that simply would not be
> an issue if VMS was based around an higher-level language instead.

But it is an observable fact that it is not needed.

>>> Since they are visible, and since they are of no use to a normal
>>> compiled language, there must be some cases where you have to
>>> preserve these values manually in Macro-32, whereas a OS based
>>> around a higher-level language would have its compilers generate
>>> the correct code sequences for you without you having to worry
>>> about any of this at all.
>>
>> So it is there for Macro-32 because VMS C could have had a feature
>> but actually does not that does something that nobody seems to be doing?
>>
>
> No, it's there because the lowest supported application language on
> VMS is Macro-32 instead of C or another language and hence that had
> to be factored into the VMS API design.
>
>> And are there really any difference between the non-existing C:
>>
>> int __damn_ast foobar()
>>
>> and the non-existing Macro-32:
>>
>> .entry foobar
>> .damn_ast
>>
>
> Yes. Code generation in a compiled language is totally abstracted
> away from the source code the compiler is working with.

Except that it is not.

The compiler does what it is instructed to do.

In this case a fictive __damn_ast directive.

> In Macro-32, the assembler is translating the source code, not
> rewriting it, and hence there are only a small number of transformations
> it can do on the source code.

And the MAcro-32 use a fictive damn_ast macro.

In both cases something get added to the code that causes
the compiler to output some code that does something.

Arne

[Simon Clubley]

On 2021-11-24, Dave Froble <da...@tsoft-inc.com> wrote:
> On 11/24/2021 8:31 AM, Simon Clubley wrote:
>>
>> Fine. So why are these architecture-specific registers passed to what
>> is essentially a callback function in a normal application program
>> and why do those registers need to be visible from that same callback
>> function ?
>>
>

> Steve Hoffman answered that question way back up-thread. I'll leave it as an
> exercise for you to go back and take a look.
>

Thank you David, I have found that posting.

So basically, I was right that the VMS abstraction layers are horribly
broken when it comes to ASTs even though the reason is a bit different
(and worse) than what I was expecting.

In other operating systems that have this functionality, this is either
handled by the compiler generating the appropriate code sequences after
the function is tagged by the programmer or is handled directly by the
underlying OS ABI _before_ calling the routine.

In either case, the saved registers are private to the OS ABI or compiler
and are _not_ visible to the user code.

But to directly push values into the call frame for the routine (and hence
directly visible to the routine) so they can be restored afterwards is just
horrible, horrible, horrible. I have never seen another OS handle this
problem in such an ugly way.

[Simon Clubley]

On 2021-11-24, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> On 11/24/2021 9:08 AM, Simon Clubley wrote:
>>
>> I suggested it was needed because clearly something needs to be manually
>> preserved by the programmer in Macro-32 code that simply would not be
>> an issue if VMS was based around an higher-level language instead.
>
> But it is an observable fact that it is not needed.
>

Turns out it's not the programmer who needs to preserve the registers
but the OS and it turns out that VMS did it by pushing the registers
directly into the user-visible call frame and hence making them directly
available to the callback function. :-(

That is incredibly ugly. It should have been handled by either the
compiler itself generating the required AST code sequence or the OS ABI
saving the registers privately outside of the user-visible call frame
before calling the AST.

Yuck.

[Arne Vajhøj]

On 11/24/2021 1:34 PM, Simon Clubley wrote:
> On 2021-11-24, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 11/24/2021 9:08 AM, Simon Clubley wrote:
>>>
>>> I suggested it was needed because clearly something needs to be manually
>>> preserved by the programmer in Macro-32 code that simply would not be
>>> an issue if VMS was based around an higher-level language instead.
>>
>> But it is an observable fact that it is not needed.
>
> Turns out it's not the programmer who needs to preserve the registers
> but the OS and it turns out that VMS did it by pushing the registers
> directly into the user-visible call frame and hence making them directly
> available to the callback function. :-(
>
> That is incredibly ugly. It should have been handled by either the
> compiler itself generating the required AST code sequence or the OS ABI
> saving the registers privately outside of the user-visible call frame
> before calling the AST.

So do we now agree that the Macro-32 thing was pure manure?

:-)

Arne

[Arne Vajhøj]

Now I followed Robert Gezeltzer's advice and it is worth noting that
this is really a VAX thing. The newer platforms do not use the values -
they are just there for VAX compatibility.

Arne

[Simon Clubley]

I agree that the real reason for them being there is so horrible
and ugly that it never occurred to me as a possibility. :-)

VMS should have been designed 5-10 years later on than when it was.

It would have been so much cleaner internally if it had been.

[Dave Froble]

On 11/24/2021 9:12 AM, Simon Clubley wrote:

> On 2021-11-24, VAXman- @SendSpamHere.ORG <VAX...@SendSpamHere.ORG> wrote:
>> In article <snlerq$jrr$1...@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>
>>> Fine. So why are these architecture-specific registers passed to what
>>> is essentially a callback function in a normal application program
>>> and why do those registers need to be visible from that same callback
>>> function ?
>>
>> Stop there! You stated crap, pure unadulterated crap! Answer the initial
>> question! You're trying to drag this off the main street and down a side
>> alley where it'll be lost amongst the riff-raff.
>>
>
> No, I am not. Are the arguments passed to the AST because the Macro-32
> programmer has to manually preserve them in some cases ?
>
> The same kind of thing that a programmer would never have to worry
> about if the lowest supported language on VMS was not Macro-32 ?
>
> Simon.
>

On VAX Macro-32 is an assembler, not a compiled language. Nothing wrong with
that. Note also that the VAX 11/780 was first available in 1978. Trying to
blame the VAX for not having things that didn't exist back then is rather
unfair, to say the least.

On Alpha, itanic, and x86 Macro-32 is a compiled language. Yes, a rather poor
compiled language. But it's existence allowed applications to be easily ported
to Alpha, then itanic, and soon x86. Now, that is a very huge capability.
Allowed Alphas to be sold, and applications to continue doing the job they were
implemented to do. For myself, I have a database product implemented in
Macro-32 that is still in use and doing very well.

That compatibility that you so despise allowed Alphas to be sold, applications
to be ported, saved a large expense, and in general was/is a good thing. If you
cannot understand that, we'll never agree.

[John Dallman]

In article <snm2ts$oc3$1...@dont-email.me>,

clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:

> VMS should have been designed 5-10 years later on than when it was.

Would DEC have survived that long without it? Would it have been
successful in the environment of the time?

John

[Arne Vajhøj]

On 11/24/2021 2:14 PM, Simon Clubley wrote:
> VMS should have been designed 5-10 years later on than when it was.
>
> It would have been so much cleaner internally if it had been.

Then Data General may still be around.

;-)

Arne

[Bill Gunshannon]

And PR1ME, too. :-)

bill

[Hunter Goatley]

On 11/24/2021 1:14 PM, Simon Clubley wrote:
>
> VMS should have been designed 5-10 years later on than when it was.
>

In a thread of backpedaling inanities, that has to be the most inane.

Hunter

[Bob Gezelter]

Arne,

Writing a better linkage is not a particularly difficult task. One is somewhat limited by the limitation that two values are passed, the AST Entry Address and the AST Parameter.

On more than a few occasions, particularly when using ASTs with QIO on the RSX-11 family using 16-bit integers, where ASTPARM was not available, the straightforward solution was to use a data structured headlined by the IO Status Block. Alternatively, one could create a transfer vector which did nothing more than set up the context and pass control to an identified routine via a pointer.

On OpenVMS (all architectures) on, e can do something similar, either hiding the non-ASTPARM parameters, or loading certain parameters from a data structure and then invoking a routine.

It is only a problem in that some languages, e.g.. C can ignore extra parameters, while other languages, e.g., BASIC, actually check for the correct number of parameters. Languages which have type checking on capabilities for call gates add another complexity to this question.

Been there, done that, have draws filled with shirts.

- Bob Gezelter, http://www.rlgsc.com
P.S. Reminds me. One of the tasks on my low priority list is to add my AST seminars to the Presentations section of my www site. Some of the AST-related sessions are already online.

[Arne Vajhøj]

On 11/24/2021 5:34 PM, Bob Gezelter wrote:
> On Wednesday, November 24, 2021 at 2:00:49 PM UTC-5, Arne Vajhøj
> wrote:
>> On 11/24/2021 1:26 PM, Simon Clubley wrote:
>>> But to directly push values into the call frame for the routine
>>> (and hence directly visible to the routine) so they can be
>>> restored afterwards is just horrible, horrible, horrible. I have
>>> never seen another OS handle this problem in such an ugly way.
>> Now I followed Robert Gezeltzer's advice and it is worth noting
>> that this is really a VAX thing. The newer platforms do not use the
>> values - they are just there for VAX compatibility.
>

> Writing a better linkage is not a particularly difficult task. One is
> somewhat limited by the limitation that two values are passed, the
> AST Entry Address and the AST Parameter.
>
> On more than a few occasions, particularly when using ASTs with QIO
> on the RSX-11 family using 16-bit integers, where ASTPARM was not
> available, the straightforward solution was to use a data structured
> headlined by the IO Status Block. Alternatively, one could create a
> transfer vector which did nothing more than set up the context and
> pass control to an identified routine via a pointer.
>
> On OpenVMS (all architectures) on, e can do something similar, either
> hiding the non-ASTPARM parameters, or loading certain parameters from
> a data structure and then invoking a routine.
>
> It is only a problem in that some languages, e.g.. C can ignore extra
> parameters, while other languages, e.g., BASIC, actually check for
> the correct number of parameters. Languages which have type checking
> on capabilities for call gates add another complexity to this
> question.

Just to clarify - the advice I took was to read the IDSM.

And the AXP version explains that AXP (and presumedly I64) does
not actually restore or otherwise use arguments at return and
that they are only there for VAX compatibility. The R0 and R1
are restored from an AST stack.

Arne

[Chris Townley]

+1

--
Chris

[VAXman-]

In article <snlg1h$jrr$3...@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2021-11-24, Arne Vajhøj <ar...@vajhoej.dk> wrote:

>Not directly, but you might have to manually manage or preserve
>something in Macro-32 that an OS based around a higher-level language
>could handle for you automatically in the code generated by the
>compilers for that OS.

Might? You mean you don't know. Yet, you stated that it's purpose is
because of something lacking in Macro-32. Please, answer the original
question.

[VAXman-]

In article <snlh1r$jrr$5...@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2021-11-24, Arne Vajhøj <ar...@vajhoej.dk> wrote:

>> On 11/24/2021 8:46 AM, Simon Clubley wrote:
>>> On 2021-11-23, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>>>
>>>> 2) Why are those arguments there?
>>>>
>>>> It is not obvious to me why Macro-32 code would want to use them
>>>> any more than C or Basic code.
>>>>
>>>
>>> Nor to me. In an OS with the proper levels of abstraction, those
>>> hardware-specific registers simply should not be needed (or even
>>> visible) to a function used as the target of what is essentially
>>> just another way of doing an asynchronous callback to a function
>>> within an application.
>>
>> So why did you suggest that it was for Macro-32?
>>
>

>I suggested it was needed because clearly something needs to be manually
>preserved by the programmer in Macro-32 code that simply would not be
>an issue if VMS was based around an higher-level language instead.

Clearly something needs to be learnt by Simon before slinging manure.

[VAXman-]

In article <snlh8f$jrr$6...@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

>No, I am not. Are the arguments passed to the AST because the Macro-32
>programmer has to manually preserve them in some cases ?

Bzzzt! Sorry, you've used up all of your slither-arounds and we now have
to ask you to answer the oringinal question. Remember, you'd stated with
authority that is was because Macro-32 couldn't function without.

[VAXman-]

In article <snmbpd$ose$1...@dont-email.me>, Hunter Goatley <goath...@goatley.com> writes:
>On 11/24/2021 1:14 PM, Simon Clubley wrote:
>>

>> VMS should have been designed 5-10 years later on than when it was.
>>
>

>In a thread of backpedaling inanities, that has to be the most inane.

Well, it was Simon.

[Dave Froble]

On 11/24/2021 5:34 PM, Bob Gezelter wrote:

> On more than a few occasions, particularly when using ASTs with QIO on the
> RSX-11 family using 16-bit integers, where ASTPARM was not available, the
> straightforward solution was to use a data structured headlined by the IO
> Status Block.

That is a neat idea. Of course, I'd not like the concept of messing with the
IOSB, but, when all else fails, it is a solution.

[Simon Clubley]

Probably not. It's a pity the timing didn't work out however.

OS design was starting to become a lot cleaner by the start of
the 1980s and much cleaner by the end of the 1980s.

A VMS designed several years later would not have had the albatross
of Macro-32 as an application programming language and as a system
implementation language hanging around it.

Think about the trends of that time period. By the early 1980s, OS
designs in a HLL (Unix for example) were standard and by the late
1980s DEC was proposing Prism with Pillar as the system implementation
language.

[Simon Clubley]

On 2021-11-24, VAXman- @SendSpamHere.ORG <VAX...@SendSpamHere.ORG> wrote:
>

> Might? You mean you don't know. Yet, you stated that it's purpose is
> because of something lacking in Macro-32. Please, answer the original
> question.
>

Already answered in another reply Brian.

[VAXman-]

In article <sno35i$lmh$5...@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

>On 2021-11-24, VAXman- @SendSpamHere.ORG <VAX...@SendSpamHere.ORG> wrote:
>>
>> Might? You mean you don't know. Yet, you stated that it's purpose is
>> because of something lacking in Macro-32. Please, answer the original
>> question.
>>
>

>Already answered in another reply Brian.

No, you haven't.

[VAXman-]

In article <sno33i$lmh$4...@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2021-11-24, John Dallman <j...@cix.co.uk> wrote:
>> In article <snm2ts$oc3$1...@dont-email.me>,
>> clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
>>
>>> VMS should have been designed 5-10 years later on than when it was.
>>
>> Would DEC have survived that long without it? Would it have been
>> successful in the environment of the time?
>>
>
>Probably not. It's a pity the timing didn't work out however.
>
>OS design was starting to become a lot cleaner by the start of
>the 1980s and much cleaner by the end of the 1980s.
>
>A VMS designed several years later would not have had the albatross
>of Macro-32 as an application programming language and as a system
>implementation language hanging around it.

The Albatross is a magnificent glider, capable of staying aloft for hours at
a time without flapping its wings.

Sounds like VMS uptimes! It seems Macro-32 wasn't so bad after all as you've
pointed out just now.

[Johnny Billquist]

On 2021-11-25 06:42, Dave Froble wrote:
> On 11/24/2021 5:34 PM, Bob Gezelter wrote:
>> On more than a few occasions, particularly when using ASTs with QIO on
>> the
>> RSX-11 family using 16-bit integers, where ASTPARM was not available, the
>> straightforward solution was to use a data structured headlined by the IO
>> Status Block.
>
> That is a neat idea.  Of course, I'd not like the concept of messing
> with the IOSB, but, when all else fails, it is a solution.

??? You're not messing with the IOSB. It's just that your I/O have some
context and information, and you keep that in a structure that also
contains the IOSB. And when the AST comes, you get the pointer to the
IOSB, and hence also the pointer to your data structure with all the
rest of the context for your I/O.

Johnny

[Dave Froble]

The IOSB is a structure that you set up, and pass a pointer to the structure.
Yeah, as you mention.

1) neat idea to use the structure

2) offends my sense of how things should be to use the structure for other than
intended

All I was trying to say. I try to avoid such "smart ideas", since they can be
obscure. But I'd use if if that was the only solution, with lots of comments.

[Chris Scheers]

In a way, Data General is still around.

http://www.wild-hare.com/products/

Disclaimer: I wrote the 32-bit emulation in eMV.

Just like PDP-11 and MVII systems, these systems still turn up in odd
corners, and their support companies have been gone longer.

--
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360 Internet: ch...@applied-synergy.com
Fax: 817-237-3074

[Andrew Commons]

You can find a complete official example in BASIC here:

http://odl.sysworks.biz/disk$axpdocdec001/opsys/vmsos721/5935/5935pro_015.html#5935disable_broadcast_trapping

[Andrew Commons]

On Wednesday, 1 December 2021 at 11:07:05 am UTC+10:30, Andrew Commons wrote:
> You can find a complete official example in BASIC here:
>
> http://odl.sysworks.biz/disk$axpdocdec001/opsys/vmsos721/5935/5935pro_015.html#5935disable_broadcast_trapping

And you might also want to check this:

http://odl.sysworks.biz/disk$axpdocmar021/opsys/vmsos73/vmsos73/6136/6136pro_017.html#mbx_interact

[Craig A. Berry]

On 11/30/21 6:37 PM, Andrew Commons wrote:
> You can find a complete official example in BASIC here:
>
> http://odl.sysworks.biz/disk$axpdocdec001/opsys/vmsos721/5935/5935pro_015.html#5935disable_broadcast_trapping
>

I already posted that way up-thread a couple of weeks ago:

<https://groups.google.com/g/comp.os.vms/c/TbtTpsImDnY/m/_b1WRX9KAAAJ>

along with a note that the example does not work out of the box on
Itanium, or (presumably) x86_64. Function signatures are more strict on
non-VAX and non-Alpha and you can't just pretend that a subroutine and a
function are the same thing. But with minor fixes, and as far as
handling AST parameters, it's an example that works.

[Andrew Commons]

Craig, sorry, missed that amongst all the off-topic posts.